GANTT and Agile Planning
GANTT Charts not compatible with agile
Why GANTT charts were banned in the first scrum
They have some utility when a Product Owner has to present an idea to naive users to get a project funded. Knows once they start development, all plans are shattered and they need to self-organise themselves.
Taking a GANTT chart into a sprint for people to look at is wrong after the first day. It takes full time resources in effort to keep them on time, and it can easily lead a team to do the wrong thing and lose.
GANTT chart was banned from sprints when they were first implemented in SCRUM. No reason to change it, top companies top priority is to get their burn down charts updated daily and visible to the entire company. Any distraction by GANTT charts is an exercise in futility.
GANTT charts could be used in agile
Agile Sprint Planning and Gantt Chart Method
Agile methodology was conceived out of a need to address the most recurrent inefficiencies that came with other project management methodologies.
Agile centres around the notion of iterative development, where organisation, collaboration and cross-functional streams become pivotal to the software development process
Sprint planning - Core of the Agile method, organise work into fixed, boxed intervals of time which team need to meet.
Before each sprint need to have a planning session, which identify two crucial decisions; Sprint Goal, and the Spring Backlog; which refers to the list of tasks that will need to be performed during the Sprint to reach the end goal.
Gantt Charts and Sprint Planning
Spring Tracking
Effective visual representation of a project which allows for an exhaustive task tracking across the entire life cycle of a project. Useful across sprints as they offer a chronologically helpful and simple way to capture goals. Can also add dependencies for each task and sprint.
Software and Team Collaboration
Collaboration is key. For teams they can be outdated and too complex, but since being online they have evolved since and have became more useful.
Agile time planning
71% of organisations have adopted agile planning and 60% of these companies increased their profits after doing so.
What is Agile planning
Agile planning has an incremental, iterative approach. Agile leaves room for requirement changes through and relies on constant feedback from the end user.
The Scrum approach to planning
The main difference between Scrum and Agile is that while Agile is a project management style, Scrum is just one of various approaches to following that framework. Just as with Agile planning, its goal is to create a functional product that delivers value to the user.
Choose items from the backlog to implement during the next sprint. Have a ceremonies where the team:
- plan next sprint and what to accomplish
- Gets team members on the same page
- Demo what they've done and talk about what went well and what didn't
4 Essential Characteristics of agile planning
1. An agile project plan is divided into releases and sprints
Define a release as creating a new product or substantially updating an existing product. Each one broken down into separate sprints. User Stories - Items in which people have to work through. The release plan is broken down into several iterations (sprints) that include user stories (items)
2. Planning is based on user stories
In agile planning, team only documents what the user needs. Throughout the sprint, team figures out how to address that specific need in the best way possible
3. Planning is iterative and incremental
Sprints are equal lengths. At end of each sprint, should result in working features which can be rolled out to the end-user. Iterative process allows team to know how many stories they can complete in a given time fame.
4. Estimation is done by team members themselves
Dev team participate in planning and estimation. Can assign points for how complex they are and based on the developers understanding of the work involved.
The agile project scheduling process
- Discuss the needed features
- Discuss the details - involved in each feature, and factors that can influence delivery. Would include the infrastructure required, risk, and external dependencies.
- Decide how much work - how much the team can commit in each sprint.
- List the stories and epics(larger dev task broken down into smaller user stories)
- Add an iteration - What team members will work on for the following two weeks
- Add stories to the iteration - until it reaches maximum capacity
- Add more iterations - until all user stories are covered.
- Share the plan - show all team members
Sprint Planning Process
- Hold a retrospective meeting
- Run a sprint planning meeting - analyse the release plan and update it accordingly
- Make sure user stories are detailed enough
- Break down user stories into specific tasks - keep tasks small, no more than one workday
- Assign tasks to team members - ensure they are committed to performing them
- Write the tasks on (physical) sticky cards
- Track the progress of all the tasks - whos doing it, estimated time, remaining actual etc
- Track velocity using a burndown chart - Number of tasks or hours remaining vs the plan, slope shows if your ahead or behind schedule
Daily Standup Meeting
- Max duration of 15 mins
- Each member no more than 1 min to report what they did yesterday
- Tasks should only be stated as done or not done, and report how many hours remaining
- Obstacles encountered
Using a team management tool for agile planning
Use software to help view who's doing what, how long its taking them, status etc.